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DETAILED ACTION 

1. Claims 1-20 are subject to examination. 

Response to Arguments 

2. Applicant's arguments filed 1 1/15/2006, pages 6-9, have been fully considered but they 
are not persuasive. Therefore, rejection of claims 1-20 is maintained. 

Applicant argues, "However, the Schuster et al. system very clearly does not include a 
private branch exchange. The Office action acknowledges, however, that Schuster et al. fails to 
teach load balancing and synchronously and asynchronously sending messages. Thus, in 
rejecting claims 1 - 4, it is asserted that Bowman- Amauh teaches load balancing and 
synchronously and asynchronously sending messages. The Office action further acknowledges, 
however, that neither Schuster et al. nor Bowman -Amauh teaches managing "a pool of message 
threads to balance" or, "a list of unique integers identifying ... dispatcher client ... to receive ... 
messages." Thus, in rejecting claims 5 - 16, the Office action asserts that Ben-Sachar ct al. 
teaches managing "a pool of message threads to balance" or, "a list of unique integers identifying 
... dispatcher Clients ... to receive ... messages." 

Schuster et al. teaches a packet based telephone system, i.e., a "system and method for 
providing user mobility services on a data network telephony system. User attributes may be 
transmitted from a portable information device, such as a personal digital assistant, to a voice 
communication device, such as an Ethernet-based telephone." Abstract (emphasis added). While 
Schuster et al. provides extensive discussion of PBX features provided in a non-residential 
setting, this discussion is restricted to the Schuster et al. Background. Col. 1, line 14 - col. 3, line 
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40. Moreover, Schuster et al. specifically recites that it "would be desirable to incorporate 
CLASS and PBX feature into a data network telephony system that uses a data network such as 
the Internet," i.e., a packet based telephone system. Col. 3, lines 37 -40 (emphasis added). If 
PBX features are incorporated into a packet network, why would one need a PBX as well? 
Certainly, the applicants could find nothing in Schuster et al. or any other reference of record that 
would suggest such an addition. Thus, the absence of a PBX in the Schuster et ai. exemplary 
embodiment of Figure 1, for example. See, col. 1, lines 31-41, and see, Figures 2- 15. Certainly, 
if Schuster et al. were actually to teach an Interact based digital telephone system with a PBX, 
the PBX would show up in one of the Figures or in the discussion of the figures or somewhere 
besides in the Background discussion. Instead, Schuster et al. teaches using external devices 
(PIDs 1 10, 210, 310, 410) linked through telephones to provide additional function to the system 
100, 200, 300, 400. See, eg., col. 7, line 10 -col. 8, line 48 andsee, col. 6, line 30 ("A. PID- 
Enabled Data Network Telephony System"). 

As noted here in above, an Interact server including the software dispatcher recited in 
claim 1, for example, may be added to a PBX to upgrade PBX based telephony services. With 
such an addition, PBX system "users would benefit from low cost IP telephony," as an 
intermediate solution to replacing the system. Page 1, lines 23 - 28. Thus, because Schuster et al. 
teaches a packet based system with PBX features and using external devices connected • through 
another intermediate device to provide additional functions to a packet based system; it is clear 
that Schuster 0t al. teaches away from "a software dispatcher in a telephony Interact server 
coupled between a packet network and a private branch exchange," as claim 1 recites at lines 2 - 
3. See also, claim 7, line 4, claim 12, line 2-4, and claim 16, line 4. Therefore, regardless of 
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what is taught by Bowman- Amauh, the addition of load balancing and synchronously and 
asynchronously sending messages with Schuster et al., still fails m result in the present invention 
as recited in claim 1 . Neither does the addition of managing M? a pool of message threads to 
balance" and/or "a list of unique integers identifying.., dispatcher clients ... to receive ... 
messages" add anything to the combination of load balancing and synchronously and 
asynchronously sending messages with Schuster et al. result in the present invention as recited in 
claims 7, 12 or 16. 

The examiner respectfully disagrees in response to applicant's arguments. Contrary to 
applicant's assertions, the teachings of the cited references are not limited as concluded by the 
applicant as mentioned above. The applicant to cite the alternative teachings of the reference 
does not mean the teachings of the broadly claimed invention taught by the cited arts should not 
be considered. 

In fact, when reviewing a reference the applicants should remember that not only the 
specific teachings of a reference but also reasonable inferences which the artisan would have 
logically drawn therefrom may be properly evaluated in formulating a rejection. In re Preda, 401 
F. 2d 825, 159 USPQ 342 (CCPA 1968) and In re Shepard, 319 F. 2d 194, 138 USPQ 148 
(CCPA 1963). Skill in the art is presumed. In re Sovish, 769 F. 2d 738, 226 USPQ 771 (Fed. 
Cir. 1985). Furthermore, artisans must be presumed to know something about the art apart from 
what the references disclose. In re Jacoby, 309 F. 2d 513, 135 USPQ 317 (CCPA 1962). The 
conclusion of obviousness may be made from common knowledge and common sense of a 
person of ordinary skill in the art without any specific hint or suggestion in a particular reference. 
In re Bozek, 416 F.2d 1385, 163 USPQ 545 (CCPA 1969). Every reference relies to some extent 
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on knowledge of persons skilled in the art to complement that which is disclosed therein. In re 
Bode, 550 F. 2d 656, 193 USPQ 12 (CCPA 1977). 

Schuster-3Com discloses a system (system that provides user access to voice and data 
network services, col., 3, lines 53 - 59, incorporating CLASS and PBX features into a data 
network telephony system that uses a data network such as the Internet, col, 3, lines 38 - 40) 
comprising: 

a software dispatcher (usage of function that support registering information col., 17, 
lines 1-11, processing the call by referencing a registration database and directing the call to the 
voice communication device, step 1506 of figure 15) in a telephony Internet server (usage of 
Internet Telephony Gateway, col., 6, lines 51-60, col., 10, lines 26 - 34) coupled between a 
packet network (IP network, Ethernet LAN, VoIP on Internet, col., 6, lines 45 - 54) and a private 
branch exchange (PSTN and PSTN Central Office, col., 6, lines 48-61, usage of PBX, col., 3, 
lines 38 - 40), the software dispatcher configured to dynamically (dynamic support of phone 
features for a user, col., 4, lines 16 - 21) add software system application features (available 
features for the user, i.e., Camp-on queuing, Call forwarding, col., 2, lines 25 - 44, phone 
forwarding, col., 4, lines 16 - 22, transfer of user attributes, col, 4, lines 32 - 36, preferences of 
the user for the phone operation, col., 4, lines 9-11, functionality available to the user, col., 7, 
lines 29-31, that is similar to the features of the specification of this application under 
prosecution) associated with and handle information (usage of voice and data network services 
for handling calls, col., 3, lines 53 - 59) between said private branch exchange (Internet 
Telephony Gateway, col., 6, lines 51-60, col., 10, lines 26 - 34) and said packet network (PSTN 
and PSTN Central Office, col., 6, lines 48 - 61, usage of PBX, col., 3, lines 38 - 40) and adapted 
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to maintain (usage of registration database maintained by the registration server, col., 4, lines 63 
- 65) a list of dispatcher clients (usage of registration database for user attributes associated with 
users of respective communication device, col., 24, lines 8-17, registration of the owner/user 
information with the information of the data network telephone in a database, col., 3, lines 60 - 
67); and 

a plurality of dispatcher clients (users of respective communication device, col., 24, lines 
8-17, owner/user of the data network telephones, col., 3, lines 60 -67); adapted to identify 
(usage user identification information, col., 3, lines 61 - 64, col., 7, lines 13 - 18, col., 11, lines 
32 - 35) to said software dispatcher particular messages (messages containing session 
information, col., 12, lines 59 - 66, multiple messages containing type of the message, payload 
type field, payload, data types, data coded as G.71 1 with a payload type code of 0, PID data with 
a payload type code of 1 90, type of channels (RTP and UDP) information, multiple data types 
with a data channel with multiple different types of packets, col., 23, lines 3 - 24, that is similar 
to the messages of the specification of this application under prosecution) for receiving 
(maintaining telephony communication, col., 12, lines 26 - 30, col., 22, lines 34 - 44); 

said software dispatcher adapted to send messages (messages for session information sent 
back and forth, col., 12, lines 59 - 66) to said plurality of dispatcher clients (users of respective 
communication device, col., 24, lines 8 - 17, owner/user of the data network telephones, col., 3, 
lines 60 -67). 

Bowman- Amuah-Accenture discloses well-known concepts of using balance system 
workload (paragraphs 1130, 1153, 1729, 1734, 1754, 1790,3370, 3405,3652,4115-4117,4125, 
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4126) and sending messages synchronously and asynchronously (voice applications / telephone 
call, paragraphs 1240, 755, 1001, 1012, 1013). 

Also, the specification of this application under prosecution at lines 2-5 of page 1 1 
clearly states, "The invention described in the above detailed description is not intended to be 
limited to the specific form set forth herein, but is intended to cover such alternatives, 
modifications and equivalents as can reasonably be included within the spirit and scope of the 
appended claims. Since, applicant's claims contain broadly claimed subject matter, it clearly 
reads upon the examiner's interpretation of the claimed subject matter. Therefore, the rejection 
is maintained., 

Claim Rejections - 35 USC §103 

3. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

4. Claims 1-4 are rejected under 35 U.S.C. 103(a) as being unpatentable over Schuster et al., 
6,446,127, 3Com Corporation (Hereinafter Schuster-3Com) in view of Bowman- Amuah, 
2003/0058277, Accenture (Hereinafter Bo wman- Amuah- Accenture). 

5. As per claim 1, Schuster-3Com discloses a system (system that provides user access to 
voice and data network services, col., 3, lines 53 - 59, incorporating CLASS and PBX features 
into a data network telephony system that uses a data network such as the Internet, col., 3, lines 
38 - 40) comprising: 



Application/Control Number: 09/742,696 Page 8 

Art Unit: 2154 

a software dispatcher (usage of function that support registering information col., 17, 
lines 1-11, processing the call by referencing a registration database and directing the call to the 
voice communication device, step 1506 of figure 15) in a telephony Internet server (usage of 
Internet Telephony Gateway, col, 6, lines 51-60, col, 10, lines 26 - 34) coupled between a 
packet network (IP network, Ethernet LAN, VoIP on Internet, col., 6, lines 45 - 54) and a private 
branch exchange (PSTN and PSTN Central Office, col., 6, lines 48-61, usage of PBX, col., 3, 
lines 3 8 - 40), the software dispatcher configured to dynamically (dynamic support of phone 
features for a user, col., 4, lines 16 - 21) add software system application features (available 
features for the user, i.e., Camp-on queuing, Call forwarding, col., 2, lines 25 - 44, phone 
forwarding, col., 4, lines 16-22, transfer of user attributes, col., 4, lines 32 - 36, preferences of 
the user for the phone operation, col, 4, lines 9-11, functionality available to the user, col., 7, 
lines 29-31, that is similar to the features of the specification of this application under 
prosecution) associated with and handle information (usage of voice and data network services 
for handling calls, col., 3, lines 53 - 59) between said private branch exchange (Internet 
Telephony Gateway, col., 6, lines 51-60, col., 10, lines 26 - 34) and said packet network (PSTN 
and PSTN Central Office, col., 6, lines 48-61, usage of PBX, col., 3, lines 38 - 40) and adapted 
to maintain (usage of registration database maintained by the registration server, col., 4, lines 63 
- 65) a list of dispatcher clients (usage of registration database for user attributes associated with 
users of respective communication device, col., 24, lines 8-17, registration of the owner/user 
information with the information of the data network telephone in a database, col., 3, lines 60 - 
67); and 
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a plurality of dispatcher clients (users of respective communication device, col., 24, lines 
8-17, owner/user of the data network telephones, col., 3, lines 60 -67); adapted to identify 
(usage user identification information, col, 3, lines 61-64, col., 7, lines 13-18, col., 11, lines 
32 - 35) to said software dispatcher particular messages (messages containing session 
information, col., 12, lines 59 - 66, multiple messages containing type of the message, payload 
type field, payload, data types, data coded as G.71 1 with a payload type code of 0, PED data with 
a payload type code of 190, type of channels (RTP and UDP) information, multiple data types 
with a data channel with multiple different types of packets, col., 23, lines 3 - 24, that is similar 
to the messages of the specification of this application under prosecution) for receiving 
(maintaining telephony communication, col., 12, lines 26 - 30, col., 22, lines 34 - 44); 

said software dispatcher adapted to send messages (messages for session information sent 
back and forth, col., 12, lines 59 — 66) to said plurality of dispatcher clients (users of respective 
communication device, col., 24, lines 8 - 17, owner/user of the data network telephones, col., 3, 
lines 60 -67). 

However, Schuster-3Com does not specifically mention about balance system workload 
and sending messages synchronously and asynchronously. 

Bowman- Amuah-Accenture discloses well-known concepts of using balance system 
workload (paragraphs 1130, 1153, 1729, 1734, 1754, 1790, 3370, 3405,3652,4115-4117,4125, 
4126) and sending messages synchronously and asynchronously (voice applications / telephone 
call, paragraphs 1240, 755, 1001, 1012, 1013). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to combine the teachings of Schuster-3Com with the teachings of Bowman- Amuah- 
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Accenture in order to facilitate usage of balance system workload because it would enhance 
handling the workload and improve overall system performance. The concept of balancing the 
workload would help distribute the workload among the entities that support processing the 
workload. Distributing the workload based on determination of the available entity among the 
entities would utilize the available entity for faster processing of the workload. Sending 
messages synchronously and asynchronously would support improving performance of the 
system by recovering information of the lost messages in the system (please see paragraphs 
1130, 1153, 1729, 1734, 1754, 1790,3370, 3405,3652,4115-4117,4125,4126, 1240, 755, 
1001, 1012, 1013). 

6. As per claim 2, Schuster-3Com and Bowman-Amuah-Accenture disclose the claimed 
limitations rejected under claim 1. Schuster-3Com also discloses said software dispatcher is 
adapted to save asynchronous messages for later transmission in a logical message queues (usage 
of queuing until the callee can accept, col., 2, lines 32 - 35, col., 1, lines 41 - 43, col., 9, lines 45 
- 40, usage of asynchronous transfer mode link, col., 8, lines 5-6). 

7. As per claim 3, Schuster-3Com and Bowman-Amuah-Accenture disclose the claimed 
limitations rejected under claims 1 and 2. Schuster-3Com also discloses messages are dispatched 
to identified ones of said plurality of dispatcher clients (users that are using their respective 
communication device, col., 24, lines 8-17, owner/users utilizing the data network telephones, 
col., 3, lines 60 -67). 
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However, Schuster-3Com does not specifically mention about dispatching in order of 
dispatcher client priority. 

Bowman-Amuah-Accenture discloses well-known concept of dispatching in order of 
dispatcher client priority (usage of priority delivery, paragraph 941, priority message delivery, 
paragraph 1 150, usage of utilization based load balancing, 4118 and 4126). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to combine the teachings of Schuster-3Com with the teachings of Bowman-Amuah- 
Accenture in order to facilitate usage of dispatching in order of dispatcher client priority because 
it would enhance handling the messages by an entity having high priority and improve overall 
system performance. The concept of assigning the messages based on the priority would help 
distribute the messages to the entity that support processing the messages faster than other 
entities (please see, paragraphs 941, 1 150, 41 18 and 4126). 

8. As per claim 4, Schuster-3Com and Bowman-Amuah-Accenture disclose the claimed 
limitations rejected under claims 1 and 2. Schuster-3Com also discloses said messages being 
sent as flexible message parameters comprising name, type, and value fields (messages 
containing payload type field, source number, destination number, payload with each of the data 
types, and/or header indicating type of data, data coded as G.71 1 with a payload type code of 0, 
PID data with a payload type code of 190, multiple channels (RTP and UDP) information, 
multiple data types with a data channel with multiple different types of packets, col., 23, lines 3 - 
24, col., 22, lines 34 - 44, that is similar to the flexible message parameters of the specification 
of this application under prosecution). 
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9. Claims 5-20 are rejected under 35 U.S.C. 103(a) as being unpatentable over Schuster- 
3Com in view of Bowman- Amuah-Accenture and Ben-Shachar et al., 6,209,018, Sun 
Microsystems, Inc (Hereinafter Ben-Shachar-Sun). 

10. As per claim 5, Schuster-3Com and Bowman- Amuah-Accenture disclose the claimed 
limitations rejected under claims 1, 2 and 4. Schuster-3Com also discloses said value field 
further comprises another flexible parameter (messages containing payload type field, payload, 
data types, data coded as G.71 1 with a payload type code of 0, PID data with a payload type code 
of 190, multiple channels (RTP and UDP) information, multiple data types with a data channel 
with multiple different types of packets, col., 23, lines 3 - 24, col., 22, lines 34 - 44, that is 
similar to the flexible parameter of the specification of this application under prosecution). 

However, Schuster-3Com and Bowman-Amuah-Accenture do not specifically mention 
about usage of managing a pool of message threads. 

Ben-Shachar-Sun discloses the concept of managing a pool of message threads (usage of 
load balancing manager for balancing workloads among workers in a worker pool, col., 3, lines 
32 - 49, col., 30, lines 5-8, with multi-threads handling messages, col., 29, lines 34 - 47, col., 
8, lines 34 - 43). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to combine the teachings of Schuster-3Com and Bowman-Amuah-Accenture with the 
teachings of Ben-Shachar-Sun in order to facilitate usage of managing a pool of message threads 
because it would enhance handling the messages by the entities utilizing multi-threads for 
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improving the overall system performance. The concept of balancing the workload using the 
multi-threads would help distribute the workload among the threads supporting the entities for 
processing the workload (please see, col., 3, lines 32 - 49, col., 30, lines 5-8, col., 29, lines 34 
- 47, col., 8, lines 34 - 43). 

11. As per claim 6, Schuster-3Com and Bowman- Amuah-Accenture disclose the claimed 
limitations rejected under claim 1. Schuster-3Com also discloses each of said messages is 
identified to said software dispatcher by a message number (usage of multiple messages 
containing type of the message, payload type field, payload, data types, data coded as G.71 1 with 
a payload type code of 0, PID data with a payload type code of 190, type of channels (RTP and 
UDP) information, multiple data types with a data channel with multiple different types of 
packets, col, 23, lines 3 - 24, col., 22, lines 34 - 44, that is similar to the message number of the 
specification of this application under prosecution). 

However, Schuster-3Com and Bowman- Amuah-Accenture do not specifically mention 
about usage of list of unique integers identifying dispatcher clients to receive messages. 

Ben-Shachar-Sun discloses the concept of list of unique integers identifying dispatcher 
clients to receive messages (usage of worker handle, col., 8, lines 34 - 38, usage of worker 
statistics, block 452 of figure 28, worker registration of figure 24, usage of registry 456, figure 
28, load balancing manager for balancing workloads among workers in a worker pool, col., 3, 
lines 32 - 49, col., 30, lines 5-8, with multi-threads handling messages, col., 29, lines 34 - 47, 
col., 8, lines 34 - 43). 
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It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to combine the teachings of Schuster-3Com and Bowman- Amuah-Accenture with the 
teachings of Ben-Shachar-Sun in order to facilitate usage of list of unique integers identifying 
dispatcher clients to receive messages because it would enhance handling the messages by the 
entities utilizing multi-threads with respective identification in order to improve the overall 
system performance. The handles of the multi-threads being unique integers would help identify 
a thread among the multi-threads that would be used for processing the messages. The concept of 
balancing the workload using the multi -threads would help distribute the workload among the 
threads supporting the entities for processing the workload (please see, col., 8, lines 34 - 38, 
col., 3, lines 32 - 49, col., 30, lines 5-8, col., 29, lines 34 - 47, col., 8, lines 34 - 43). 

12. As per claim 7, Schuster-3Com discloses a method (providing user access to voice and 
data network services, col., 3, lines 53 - 59, incorporating CLASS and PBX features into a data 
network telephony system that uses a data network such as the Internet, col., 3, lines 38 - 40) 
comprising: 

maintaining a list of dispatcher clients (registration database for user attributes associated 
with users of respective communication device, col., 24, lines 8 - 17, registration of the 
owner/user information with the information of the data network telephone in a database, col., 3, 
lines 60 -67) at a software dispatcher (usage of function that support registering information col., 
17, lines 1-11, processing the call by referencing a registration database and directing the call 
to the voice communication device, step 1506 of figure 15), said software dispatcher configured 
to dynamically (dynamic support of phone features for a user, col., 4, lines 16 - 21) add software 
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features to software subsystems (available features for the user, i.e., Camp-on queuing, Call 
forwarding, col., 2, lines 25 - 44, phone forwarding, col, 4, lines 16 - 22, transfer of user 
attributes, col., 4, lines 32 - 36, preferences of the user for the phone operation, col., 4, lines 9 - 
11, usage of Internet Telephony Gateway, col., 6, lines 51-60, col., 10, lines 26 - 34, 
functionality available to the user, col., 7, lines 29-31, that is similar to the features of the 
specification of this application under prosecution) between a packet network (IP network, 
Ethernet LAN, VoIP on Internet, col., 6, lines 45 - 54) and a private branch exchange (PSTN and 
PSTN Central Office, col., 6, lines 48 - 61, usage of PBX, col., 3, lines 38 - 40), said dispatcher 
clients comprising software subsystems (software handling respective communication device of 
the users as per the user attributes associated, col., 24, lines 8-17, col., 3, lines 60 -67) said list 
comprising identifying particular messages (usage of multiple messages containing type of the 
message, payload type field, payload, data types, data coded as G.71 1 with a payload type code 
of 0, PID data with a payload type code of 190, type of channels (RTP and UDP) information, 
multiple data types with a data channel with multiple different types of packets, col., 23, lines 3 - 
24, col, 22, lines 34 - 44, that is similar to the messages of the specification of this application 
under prosecution), said dispatcher clients registering (usage of registration database for user 
attributes associated with users of respective communication device, col., 24, lines 8-17, 
registration of the owner/user information with the information of the data network telephone in 
a database, col., 3, lines 60 -67) to receive predetermined messages with said dispatcher 
(messages containing session information, col., 12, lines 59 - 66, voice versus data network 
services information, col., 3, lines 53 - 59). 
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dispatching messages to said dispatcher clients (messages for session information sent 
back and forth, col., 12, lines 59 - 66, users of respective communication device, col., 24, lines 8 
- 17, owner/user of the data network telephones, col., 3, lines 60 -67). 

However, Schuster-3Com does not specifically mention about balance workload and 
dispatching messages synchronously and asynchronously. 

Bowman- Amuah-Accenture discloses well-known concepts of using balance workload 
(paragraphs 1130, 1153, 1729, 1734, 1754, 1790, 3370, 3405, 3652, 4115-4117, 4125, 4126) and 
dispatching messages synchronously and asynchronously (voice applications / telephone call, 
paragraphs 1240, 755, 1001, 1012, 1013). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to combine the teachings of Schuster-3Com with the teachings of Bowman- Amuah- 
Accenture in order to facilitate usage of balance system workload because it would enhance 
handling the workload and improve overall system performance. The concept of balancing the 
workload would help distribute the workload among the entities that support processing the 
workload. Distributing the workload based on determination of the available entity among the 
entities would utilize the available entity for faster processing of the workload. Dispatching 
messages synchronously and asynchronously would support improving performance of the 
system by recovering information of the lost messages in the system (please see paragraphs 
1130, 1153, 1729, 1734, 1754, 1790,3370, 3405,3652,4115-4117,4125,4126, 1240, 755, 
1001, 1012, 1013). 

However, Schuster-3Com and Bowman-Amuah-Accenture do not specifically mention 
about usage of list of unique integers identifying dispatcher clients to receive messages. 
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Ben-Shachar-Sun discloses the concept of list of unique integers identifying dispatcher 
clients to receive messages (usage of worker handle, col., 8, lines 34 - 38, usage of worker 
statistics, block 452 of figure 28, worker registration of figure 24, usage of registry 456, figure 
28, load balancing manager for balancing workloads among workers in a worker pool, col., 3, 
lines 32 - 49, col., 30, lines 5-8, with multi-threads handling messages, col, 29, lines 34 - 47, 
col., 8, lines 34 - 43). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to combine the teachings of Schuster-3Com and Bowman- Amuah-Accenture with the 
teachings of Ben-Shachar-Sun in order to facilitate usage of list of unique integers identifying 
dispatcher clients to receive messages because it would enhance handling the messages by the 
entities utilizing multi-threads with respective identification in order to improve the overall 
system performance. The handles of the multi-threads being unique integers would help identify 
a thread among the multi-threads that would be used for processing the messages. The concept of 
balancing the workload using the multi-threads would help distribute the workload among the 
threads supporting the entities for processing the workload (please see, col., 8, lines 34 - 38, 
col., 3, lines 32 - 49, col, 30, lines 5-8, col, 29, lines 34 - 47, col., 8, lines 34 - 43). 

13. As per claim 8, Schuster-3Com, Bowman- Amuah-Accenture and Ben-Shachar-Sun 
disclose the claimed limitations rejected under claim 7. Schuster-3Com also discloses saving 
asynchronous messages for later transmission in a logical message queues (usage of queuing 
until the callee can accept, col., 2, lines 32 - 35, col., 1, lines 41 - 43, col., 9, lines 45 - 40, usage 
of asynchronous transfer mode link, col., 8, lines 5-6). 
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14. As per claim 9, Schuster-3Com, Bowman-Amuah-Accenture and Ben-Shachar-Sun 
disclose the claimed limitations rejected under claims 7 and 8. 

Bowman-Amuah-Accenture also discloses well-known concept of dispatching in order 
of dispatcher client priority (usage of priority delivery, paragraph 941, priority message delivery, 
paragraph 1 150, usage of utilization based load balancing, 4118 and 4126). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to combine the teachings of Schuster-3Com, Bowman-Amuah-Accenture and Ben- 
Shachar-Sun in order to facilitate usage of dispatching in order of dispatcher client priority 
because it would enhance handling the messages by an entity having high priority and improve 
overall system performance. The concept of assigning the messages based on the priority would 
help distribute the messages to the entity that support processing the messages faster than other 
entities (please see, paragraphs 941, 1 150, 4118 and 4126). 

15. As per claim 10, Schuster-3Com, Bowman-Amuah-Accenture and Ben-Shachar-Sun 
disclose the claimed limitations rejected under claims 7-9. Schuster-3Com also discloses said 
dispatching messages as flexible message parameters comprising name, type, and value fields 
(messages containing payload type field, source number, destination number, payload with each 
of the data types, and/or header indicating type of data, data coded as G.71 1 with a payload type 
code of 0, PED data with a payload type code of 190, multiple channels (RTP and UDP) 
information, multiple data types with a data channel with multiple different types of packets, 
col., 23, lines 3 - 24, col., 22, lines 34 - 44, that is similar to the flexible message parameters of 
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the specification of this application under prosecution), wherein only dispatcher clients 
(registered users only in the registration database for user attributes associated with users of 
respective communication device, col., 24, lines 8 - 17, col., 3, lines 60 -67) identified to receive 
particular messages (multiple messages, col., 23, lines 3 - 24) is aware of both content and 
destination of respective said particular messages (multiple messages containing type of the 
message, pay load type field, payload, data types, data coded as G.71 1 with a payload type code 
of 0, PED data with a payload type code of 190, type of channels (RTP and UDP) information, 
multiple data types with a data channel with multiple different types of packets, col, 23, lines 3 - 
24, col., 22, lines 34 - 44, that is similar to the messages of the specification of this application 
under prosecution). 

16. As per claim 11, Schuster-3Com, Bowman- Amuah-Accenture and Ben-Shachar-Sun 
disclose the claimed limitations rejected under claim 7. Ben-Shachar-Sun also discloses 
managing a pool of message threads (usage of load balancing manager for balancing workloads 
among workers in a worker pool, col., 3, lines 32 - 49, col, 30, lines 5-8, with multi-threads 
handling messages, col., 29, lines 34 - 47, col., 8, lines 34 - 43). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to combine the teachings of Schuster-3Com, Bowman- Amuah-Accenture and Ben- 
Shachar-Sun in order to facilitate usage of managing a pool of message threads because it would 
enhance handling the messages by the entities utilizing multi-threads for improving the overall 
system performance. The concept of balancing the workload using the multi-threads would help 
distribute the workload among the threads supporting the entities for processing the workload 
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(please see, col., 3, lines 32 - 49, col., 30, lines 5-8, col., 29, lines 34 - 47, col., 8, lines 34 - 
43). 

17. As per claim 12, Schuster-3Com discloses a telecommunication system (incorporating 
CLASS and PBX features into a data network telephony system that uses a data network such as 
the Internet, col., 3, lines 38 - 40) comprising: 

a private branch exchange (PSTN and PSTN Central Office, col., 6, lines 48-61, usage 
of PBX, col, 3, lines 38 - 40), 

a server (usage of Internet Telephony Gateway, col., 6, lines 51 - 60, col., 10, lines 26 - 
34, functionality available to the user, col., 7, lines 29-31) coupled (IP network, Ethernet LAN, 
VoIP on Internet, col., 6, lines 45 - 54) to the private branch exchange (PSTN and PSTN Central 
Office, col., 6, lines 48-61, usage of PBX, col., 3, lines 38 - 40), the server adapted to interface 
the private branch exchange to a packet network (IP network, Ethernet LAN, VoIP on Internet, 
col., 6, lines 45 - 54); 

a software dispatcher in said server (usage of function that support registering 
information col., 17, lines 1-11, processing the call by referencing a registration database and 
directing the call to the voice communication device, step 1506 of figure 15), adapted to receive 
and dispatch message (usage of multiple messages containing type of the message, payload type 
field, payload, data types, data coded as G.71 1 with a payload type code of 0, PID data with a 
payload type code of 190, type of channels (RTP and UDP) information, multiple data types with 
a data channel with multiple different types of packets, col., 23, lines 3 - 24, col., 22, lines 34 - 
44, that is similar to the message of the specification of this application under prosecution) for 
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dynamically (dynamic support of phone features for a user, col., 4, lines 16 - 21) adding 
software features (available features for the user, i.e., Camp-on queuing, Call forwarding, col., 2, 
lines 25 - 44, phone forwarding, col., 4, lines 16 - 22, transfer of user attributes, col., 4, lines 32 
- 36, preferences of the user for the phone operation, col, 4, lines 9-11, usage of Internet 
Telephony Gateway, col., 6, lines 51 - 60, col., 10, lines 26 - 34, functionality available to the 
user, col., 7, lines 29-31, that is similar to the features of the specification of this application 
under prosecution) to software subsystem (software handling respective communication device 
of the users / clients as per the associated user attributes, col., 24, lines 8-17, col., 3, lines 60 - 
67), . 

the dispatcher identifying and distributing the messages by identifier (usage of multiple 
messages containing type of the message, payload type field, payload, data types, data coded as 
G.71 1 with a payload type code of 0, PED data with a payload type code of 190, type of channels 
(RTP and UDP) information, multiple data types with a data channel with multiple different 
types of packets, col., 23, lines 3 - 24, col, 22, lines 34 - 44, that is similar to the message 
identifying of the specification of this application under prosecution), and node (communication 
device, col., 24, lines 8-17, network element for the telephone, col., 3, lines 60 -67). 

However, Schuster-3Com does not specifically mention about balance workload. 

Bowman- Amuah-Accenture discloses well-known concepts of using balance workload 
(paragraphs 1130, 1153, 1729, 1734, 1754, 1790, 3370, 3405, 3652, 4115-4117, 4125, 4126). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to combine the teachings of Schuster-3Com with the teachings of Bowman- Amuah- 
Accenture in order to facilitate usage of balance system workload because it would enhance 
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handling the workload and improve overall system performance. The concept of balancing the 
workload would help distribute the workload among the entities that support processing the 
workload. Distributing the workload based on determination of the available entity among the 
entities would utilize the available entity for faster processing of the workload, (please see 
paragraphs 1130, 1153, 1729, 1734, 1754, 1790,3370, 3405,3652,4115-4117,4125,4126, 
1240,755,1001,1012,1013). 

However, Schuster-3Com and Bowman- Amuah-Accenture do not specifically mention 
about usage of unique integer for identifying. 

Ben-Shachar-Sun discloses the concept of using unique integer for identifying (usage of 
worker handle, col., 8, lines 34 - 38, usage of worker statistics, block 452 of figure 28, worker 
registration of figure 24, usage of registry 456, figure 28, load balancing manager for balancing 
workloads among workers in a worker pool, col., 3, lines 32 - 49, col., 30, lines 5-8, with 
multi-threads handling messages, col., 29, lines 34 - 47, col., 8, lines 34 - 43). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to combine the teachings of Schuster-3Com and Bowman- Amuah-Accenture with the 
teachings of Ben-Shachar-Sun in order to facilitate usage of list of unique integers identifying 
dispatcher clients to receive messages because it would enhance handling the messages by the 
entities utilizing multi-threads with respective identification in order to improve the overall 
system performance. The handles of the multi-threads being unique integers would help identify 
a thread among the multi-threads that would be used for processing the messages. The concept of 
balancing the workload using the multi-threads would help distribute the workload among the 
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threads supporting the entities for processing the workload (please see, col., 8, lines 34 - 38, 
col., 3, lines 32 -49, col., 30, lines 5-8, col., 29, lines 34 - 47, col., 8, lines 34 - 43). 

18. As per claim 13, Schuster-3Com 3 Bowman- Amuah-Accenture and Ben-Shachar-Sun 
disclose the claimed limitations rejected under claim 12. Ben-Shachar-Sun also discloses said 
software subsystem (software handling respective communication device of the users / clients as 
per the associated user attributes, col., 24, lines 8-17, col., 3, lines 60 -67) provide said 
dispatcher with an identification of a message to be delivered (type of message that is supported 
by the client/user software, data coded as G.71 1 with a payload type code of 0, PID data with a 
payload type code of 190, a channel among multiple supported channels (RTP and UDP), 
expected packet among multiple different types of packets, col, 23, lines 3 - 24, col., 22, lines 
34 - 44), and said dispatcher identifies a destination (a registered user / client as per associated 
user attributes for a respective communication device, col., 24, lines 8-17, col., 3, lines 60 -67), 
whereby said software subsystem is unaware (dynamic support of the message information, col., 
21, lines 1-2) of respective identified destinations (a plurality of registered users / clients as per 
associated user attributes for respective communication devices, other registered users /clients, 
col, 24, lines 8-17, col., 3, lines 60 -67). 

19. As per claim 14, Schuster-3Com, Bowman-Amuah-Accenture and Ben-Shachar-Sun 
disclose the claimed limitations rejected under claim 12. Ben-Shachar-Sun also discloses said 
dispatcher maintains a list of registered receivers (registration database for user attributes 
associated with plurality of users /clients of respective communication devices, col, 24, lines 8 - 
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17, registration of the owner/user information with the information of the data network telephone 
in a database, col., 3, lines 60 -67) and message numbers (type of messages that is supported by 
the client/user software, data coded as G.71 1 with a payload type code of 0, PID data with a 
payload type code of 190, a channel among multiple supported channels (RTP and UDP), 
expected packet among multiple different types of packets, col., 23, lines 3 - 24, col., 22, lines 
34 - 44), each distributed message being identified (sent message information, col., 21, lines 1-2) 
to said dispatcher (usage of function that support registering information col., 17, lines 1-11, 
processing the call by referencing a registration database and directing the call to the voice 
communication device, step 1506 of figure 15) by one of said message numbers (expected type 
of packet among supported multiple packets, data coded as G.71 1 with a payload type code of 0, 
PID data with a payload type code of 1 90, a channel among multiple supported channels (RTP 
and UDP), col., 23, lines 3 - 24, col., 22, lines 34 - 44). 

20. As per claim 15, Schuster-3Com, Bowman-Amuah-Accenture and Ben-Shachar-Sun 
disclose the claimed limitations rejected under claim 12. Ben-Shachar-Sun also discloses said 
software subsystem is adapted to register with said dispatcher (usage of function that support 
registering information for the users/ clients for respective devices, col, 17, lines 1-11), for 
receiving particular messages (usage of multiple messages containing type of the message, 
payload type field, payload, data types, data coded as G.71 1 with a payload type code of 0, PID 
data with a payload type code of 190, type of channels (RTP and UDP) information, multiple 
data types with a data channel with multiple different types of packets, col., 23, lines 3 - 24), and 
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the software dispatcher handles system workload (calls and voice and/or data network services 
for handling calls, col., 3, lines 53 - 59). 

However, Schuster-3Com does not specifically mention about balance system workload. 

Bowman- Amuah-Accenture discloses well-known concepts of using balance system 
workload (paragraphs 1130, 1153, 1729, 1734, 1754, 1790, 3370, 3405, 3652, 4115-4117, 4125, 
4126). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to combine the teachings of Schuster-3Com, Bowman- Amuah-Accenture and Ben- 
Shachar-Sun in order to facilitate usage of balance system workload because it would enhance 
handling the workload and improve overall system performance. The concept of balancing the 
workload would help distribute the workload among the entities that support processing the 
workload. Distributing the workload based on determination of the available entity among the 
entities would utilize the available entity for faster processing of the workload, (please see 
paragraphs 1130, 1153, 1729, 1734, 1754, 1790, 3370, 3405, 3652, 4115-4117, 4125, 4126, 
1240, 755, 1001, 1012, 1013). 

However, Schuster-3Com and Bowman- Amuah-Accenture do not specifically mention 
about maintaining a pool of message threads. 

Ben-Shachar-Sun discloses the concept of maintaining a pool of message threads (usage 
of load balancing manager for balancing workloads among workers in a worker pool, col., 3, 
lines 32 - 49, col., 30, lines 5-8, with multi-threads handling messages, col., 29, lines 34 - 47, 
col., 8, lines 34 - 43). 
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It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to combine the teachings of Schuster-3Com, Bowman- Amuah-Accenture and Ben- 
Shachar-Sun in order to facilitate usage of maintaining a pool of message threads because it 
would enhance handling the messages by the entities utilizing multi-threads for improving the 
overall system performance. The concept of balancing the workload using the multi-threads 
would help distribute the workload among the threads supporting the entities for processing the 
workload (please see, col., 3, lines 32 - 49, col., 30, lines 5-8, col., 29, lines 34 - 47, col., 8, 
lines 34 - 43). 

21 . As per claim 16, Schuster-3Com discloses a system (system that provides user access to 
voice and data network services, col., 3, lines 53 - 59, incorporating CLASS and PBX features 
into a data network telephony system that uses a data network such as the Internet, col., 3, lines 
38 -40) comprising: 

a software dispatcher configured (usage of function that support registering information 
col., 17, lines 1-11, processing the call by referencing a registration database and directing the 
call to the voice communication device, step 1506 of figure 15, usage of Internet Telephony 
Gateway, col., 6, lines 51-60, col., 10, lines 26 - 34) to dynamically (dynamic support of phone 
features for a user, col., 4, lines 16-21) add software system application features (available 
features for the user, i.e., Camp-on queuing, Call forwarding, col., 2, lines 25 - 44, phone 
forwarding, col., 4, lines 16-22, transfer of user attributes, col., 4, lines 32 - 36, preferences of 
the user for the phone operation, col, 4, lines 9-11, functionality available to the user, col., 7, 
lines 29-31, that is similar to the features of the specification of this application under 
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prosecution) to dispatcher clients (usage of registration database for user attributes associated 
with users of respective communication device, col., 24, lines 8-17, registration of the 
owner/user information with the information of the data network telephone in a database, col., 3, 
lines 60 -67) and mange workload (calls and voice and/or data network services for handling 
calls, col, 3, lines 53 - 59) between a packet network (IP network, Ethernet LAN, VoIP on 
Internet, col., 6, lines 45 - 54) and a private branch exchange (PSTN and PSTN Central Office, 
col., 6, lines 48-61, usage of PBX, col., 3, lines 38 - 40), the software dispatcher adapted to 
maintain (usage of registration database maintained by the registration server, col., 4, lines 63 - 
65) a list of dispatcher clients (usage of registration database for user attributes associated with 
users of respective communication device, col., 24, lines 8-17, registration of the owner/user 
information with the information of the data network telephone in a database, col, 3, lines 60 - 
67), messages being selectively (as per type of message that is supported by the client/user 
software, data coded as G.71 1 with a payload type code of 0, PID data with a payload type code 
of 190, a channel among multiple supported channels (RTP and UDP), , col., 23, lines 3 - 24, 
col., 22, lines 34 - 44) sent between the dispatcher clients (registered users / clients as per 
associated user attributes for a respective communication devices, col., 24, lines 8-17, col., 3, 
lines 60 -67), the dispatcher clients including software application (software supporting user / 
client, col., 24, lines 8-17, col., 3, lines 60 -67); 

a plurality of dispatcher clients (users of respective communication device, col., 24, lines 
8-17, owner/user of the data network telephones, col., 3, lines 60 -67); adapted to identify 
(usage user identification information, col., 3, lines 61 - 64, col., 7, lines 13 - 18, col., 11, lines 
32 - 35) to said software dispatcher particular messages (messages containing session 
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information, col., 12, lines 59 - 66, multiple messages containing type of the message, payload 
type field, payload, data types, data coded as G.71 1 with a payload type code of 0, PID data with 
a payload type code of 190, type of channels (RTP and UDP) information, multiple data types 
with a data channel with multiple different types of packets, col, 23, lines 3 - 24, col., 22, lines 
34 - 44) for receiving (maintaining telephony communication, col., 12, lines 26 - 30) from other 
dispatcher clients (other registered users /clients, col, 24, lines 8-17, col., 3, lines 60 -67), 
wherein said other dispatcher clients identify (available features for the user, i.e., Camp-on 
queuing, Call forwarding, col., 2, lines 25 - 44, phone forwarding, col., 4, lines 16 - 22, transfer 
of user attributes, col., 4, lines 32 - 36, preferences of the user for the phone operation, col., 4, 
lines 9-11, functionality available to the user, col, 7, lines. 29 - 31) messages (messages 
containing session information, col., 12, lines 59 - 66, multiple messages containing type of the 
message, payload type field, payload, data types, data coded as G.71 1 with a payload type code 
of 0, PED data with a payload type code of 190, type of channels (RTP and UDP) information, 
multiple data types with a data channel with multiple different types of packets, col., 23, lines 3 - 
24, col., 22, lines 34 - 44) for sending to said software dispatcher (communicating to the 
function that support registering information col., 17, lines 1-11, processing the call by 
referencing a registration database and directing the call to the voice communication device, step 
1506 of figure 15), 

said software dispatcher adapted to send messages (messages for session information sent 
back and forth, col, 12, lines 59 - 66) to identified receiving ones of said plurality of dispatcher 
clients (users of respective communication device, col, 24, lines 8-17, owner/user of the data 
network telephones, col., 3, lines 60 -67). 
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However, Schuster-3Com does not specifically mention about balance workload and 
sending messages synchronously and asynchronously. 

Bowman- Amuah-Accenture discloses well-known concepts of using balance system 
workload (paragraphs 1130, 1153, 1729, 1734, 1754, 1790, 3370, 3405, 3652, 4115-4117, 4125, 
4126) and sending messages synchronously and asynchronously (voice applications / telephone 
call, paragraphs 1240, 755, 1001, 1012, 1013). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to combine the teachings of Schuster-3Com with the teachings of Bowman- Amuah- 
Accenture in order to facilitate usage of balance system workload because it would enhance 
handling the workload and improve overall system performance. The concept of balancing the 
workload would help distribute the workload among the entities that support processing the 
workload. Distributing the workload based on determination of the available entity among the 
entities would utilize the available entity for faster processing of the workload. Sending 
messages synchronously and asynchronously would support improving performance of the 
system by recovering information of the lost messages in the system (please see paragraphs 
1130, 1153, 1729, 1734, 1754, 1790,3370, 3405,3652,4115-4117,4125,4126, 1240, 755, 
1001,1012,1013). 

However, Schuster-3Com and Bowman- Amuah-Accenture do not specifically mention 
about managing a pool of message threads. 

Ben-Shachar-Sun discloses the concept of managing a pool of message threads (usage of 
load balancing manager for balancing workloads among workers in a worker pool, col., 3, lines 
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32 - 49, col., 30, lines 5-8, with multi-threads handling messages, col., 29, lines 34 - 47, col., 
8, lines 34 - 43). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made. to combine the teachings of Schuster-3 Com, Bowman- Amuah-Accenture and Ben- 
Shachar-Sun in order to facilitate usage of managing a pool of message threads because it would 
enhance handling the messages by the entities utilizing multi-threads for improving the overall 
system performance. The concept of balancing the workload using the multi-threads would help 
distribute the workload among the threads supporting the entities for processing the workload 
(please see, col, 3, lines 32 - 49, col., 30, lines 5-8, col., 29, lines 34 - 47, col, 8, lines 34 - 
43). 

22. Referring to claims 17-20, refer to the rejections of the above-rejected similar limitations 
of the claims 1-16 for rejection and combination of references. 

Conclusion 

23. The prior art made of record (forms PTO-892 and applicant provided IDS cited arts) and 
not relied upon is considered pertinent to applicant's disclosure. 

24. Applicant is suggested to make the following amendments to the claims to define the 
scope of their invention and to distinguish over the prior art. TBD 

THIS ACTION IS MADE FINAL, Applicant is reminded of the extension of time 
policy as set forth in 37 CFR 1 .136(a). 
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A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within TWO 
MONTHS of the mailing date of this final action and the advisory action is not mailed until after 
the end of the THREE-MONTH shortened statutory period, then the shortened statutory period 
will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 
CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, 
however, will the statutory period for reply expire later than SIX MONTHS from the mailing 
date of this final action. 

Examiner has cited particular columns and line numbers and/or paragraphs and/or 
sections and/or page numbers in the reference(s) as applied to the claims above for the 
convenience of the applicant. Although the specified citations are representative of the teachings 
of the art and are applied to the specific limitations within the individual claim, other passages 
and figures may apply as well. It is respectfully requested from the applicant in preparing 
responses, to fully consider the references in entirety, as potentially teaching, all or part of the 
claimed invention, as well as the context of the passage, as taught by the prior art or disclosed by 
the Examiner. 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Haresh Patel whose telephone number is (571) 272-3973. The 
examiner can normally be reached on Monday, Tuesday, Thursday and Friday from 10:00 am to 
8:00 pm. 
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If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, John Follansbee can be reached on (571) 272-3964. The fax phone number for the 
organization where this application or proceeding is assigned is (571) 273-8300. 

Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). 



Haresh Patel 
February 1,2007 



